This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived, implemented or described. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The following abbreviations that may be found in the specification and/or the drawing figures are defined as follows:
AKA authentication and key agreement
API application program interface
AUTN authentication token
AV authentication vector
BSF bootstrapping server function
B-TID boostrapping transaction identifier
CA certification authority
CK cipher key
DNS domain name server
FQDN fully qualified domain name
GBA generic bootstrapping architecture
GBA_U GBA with UICC-based enhancements
GUSS GBA user security settings
HLR home location register
HSS home subscriber system
HTTP hypertext transfer protocol
HTTPS hypertext transfer protocol secure
IK integrity key
IMPI IMS private user identity
IMS IP multimedia subsystem
IP internet protocol
Ks_ext_NAF derived key in GBA_U
NAF network application function
NAF_ID network application function identifier
RAND random challenge
TLS transport layer security
TMPI temporary IMPI
UE user equipment
UICC universal integrated circuit card
URI uniform resource identifier
URL uniform resource locator
XRES expected response
One specification of interest herein is 3GPP TS 33.220 V9.2.0 (2009-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Generic Authentication Architecture (GAA); Generic bootstrapping architecture (Release 9), referred to hereafter for convenience as 3GPP TS 33.220. FIG. 1 herein reproduces FIG. 4.1 of 3GPP TS 33.220, “Simple network model for bootstrapping involving HSS with a reference point”, while FIG. 2 herein reproduces FIG. 4.3 of 3GPP TS 33.220, “The bootstrapping procedure”.
FIG. 1 shows the simple network model of the entities involved in the bootstrapping approach when a HSS with Zn reference point is deployed, and the various reference points (e.g., the interfaces Ub, Ua, Zn, Dz) used between them.
When the UE wants to interact with a NAF, and it knows that the bootstrapping procedure is needed, it first performs bootstrapping authentication as shown in FIG. 2, otherwise, the UE performs bootstrapping authentication only when it has received a bootstrapping initiation required message or a bootstrapping negotiation indication from the NAF, or when the lifetime of a key in the UE has expired.
The UE always includes the product token “3gpp-gba-tmpi” in a user agent request-header field when communicating over Ub. The BSF always includes the product token “3gpp-gba-tmpi” in the server response-header field when communicating over Ub.
The following steps are performed in the basic bootstrapping procedure shown in FIG. 2.
(1) The UE sends an HTTP request towards the BSF. When a TMPI associated with the IMPI in use is available on the UE, the UE includes this TMPI in the “username” parameter, otherwise the UE includes the IMPI.
(2) The BSF recognizes from the structure of the “username” parameter whether a TMPI or an IMPI was sent. If a TMPI was sent the BSF looks up the corresponding IMPI in its local database. If the BSF does not find an IMPI corresponding to the received TMPI it returns an appropriate error message to the UE. The UE then deletes the TMPI and retries the request using the IMPI.
The BSF retrieves the complete set of GBA user security settings and one Authentication Vector (AV, AV=RAND|AUTN|XRES|CK|IK) over the reference point Zh from the HSS (where indicates concatenation).
In the case that no HSS with the Zh reference point is deployed, the BSF retrieves the Authentication Vector over a reference point Zh′ from either an HLR or an HSS with Zh′ reference point support. The Zh′ reference point is defined to be used between the BSF and the HLR, and allows the BSF to fetch required authentication information (see 3GPP TS 33.220, clause 4.3.6 and clause 4.4.12).
If the BSF implements a timestamp option and has a local copy of the ‘for the subscriber that has been fetched from the HSS during a previous bootstrapping procedure, and this GUSS includes a timestamp, the BSF may include the GUSS timestamp in the request message. Upon receiving that timestamp, if the HSS implements the timestamp option, the HSS may compare it with the timestamp of the GUSS stored in the HSS. In this case, if and only if the HSS has done the comparison and the timestamps are equal, then the HSS sends a “GUSS TIMESTAMP EQUAL” indication to the BSF. In any other case, the HSS sends the GUSS (if available) to the BSF. If the BSF receives “GUSS TIMESTAMP EQUAL” indication, it keeps the local copy of the GUSS. In any other case, the BSF deletes the local copy of the GUSS and stores the received GUSS (if sent).
(3) The BSF forwards the RAND and AUTN to the UE in a 401 message (without the CK, IK and XRES). This is to demand the UE to authenticate itself.
(4) The UE checks the AUTN to verify that the challenge is from an authorized network; the UE also calculates CK, IK and RES. This will result in session keys IK and CK in both the BSF and the UE.
(5) The UE sends another HTTP request, containing the Digest AKA response (calculated using RES), to the BSF.
(6) The BSF authenticates the UE by verifying the Digest AKA response.
(7) The BSF generates key material Ks by concatenating CK and IK. The B-TID value is also generated in format of NM by taking the base64 encoded RAND value from step (3), and the BSF server name, i.e.:
base64encode(RAND)@BSF_servers_domain_name.
If the request included the product token “3gpp-gba-tmpi” in the user agent request-header field the BSF computes a new TMPI stores it together with the IMPI, overwriting a previous TMPI related to this IMPI, if any.
(8) The BSF sends a 200 OK message, including a B-TID, to the UE to indicate the success of the authentication. In addition, in the 200 OK message, the BSF supplies the lifetime of the key Ks. The key material Ks is generated in UE by concatenating CK and IK.
(9) Both the UE and the BSF use the Ks to derive the key material Ks_NAF during the procedures as specified in clauseC4.5.3. Ks_NAF is used for securing the reference point Ua.
To allow consistent key derivation based on the NAF name in the UE and the BSF, at least one of the three following prerequisites has to be fulfilled:
(a) The NAF is known in a DNS under one domain name (FQDN) only, i.e., no two different domain names point to the IP address of the NAF. This is achieved by administrative means.
(b) Each DNS entry of the NAF points to a different IP address. The NAF responds to all of these IP addresses. Each IP address is tied to the corresponding FQDN by NAF configuration. The NAF can determine from the IP address which FQDN to use for key derivation.
(c) The Ua uses a protocol which transfers the host name (FQDN of NAF as used by the UE) to the NAF (e.g. HTTP/1.1 with mandatory Host request header field). This requires the NAF to check the validity of the host name, and to use this name in all communication with the UE where appropriate, and to transfer this name to the BSF to allow for correct derivation of Ks_NAF.
The UE and the BSF store the key Ks with the associated B-TID for further use, until the lifetime of Ks has expired, or until the key Ks is updated, or until deletion conditions are satisfied.
An existing problem relates to the fact that with current standards it is not possible for a signed Web application (widget) to prove a mapping that it is allowed to act on behalf of a namespace or be identified as a certain namespace. Thus, such a widget has typically more limited access to local system resources that does a widget that has been signed by a certified application vendor.